Report the reference images of the num_ref_images window that hold no results - #148

Problem

calc_and_set_ref_intensities has two ways of picking the reference images, and only one of them was checked. The images named by ref_img_indices go through _check_requested_ref_imgs_available, which reports the ones that hold no intensity values. The first num_ref_images ones, selected with img_id <= num_ref_imgs, went through nothing.

An image that could not be read keeps its ID in the image infos but produces no intensities, so a skipped image inside the reference window dropped out of the average unnoticed:

• num_ref_images = 1 and no results for image 1: the reference intensities came back empty. The run printed Images with indices [] were used for calculating reference intensities and carried on normalising by nothing.
• num_ref_images = 3 and no results for image 1: averaged over 2 images instead of 3, silently, where the same loss among named reference images would have warned.

The first case is the one left open by #143, which only got the column names past the missing image 1. Its acceptance test had to set num_ref_images = 2 to get a usable reference at all.

Change

Both paths now build an explicit list of requested image IDs — ref_img_indices, or range(1, num_ref_imgs + 1) — and hand it to _check_requested_ref_imgs_available, which takes the IDs as an argument instead of reading ref_img_indices itself. The behaviour the named reference images already had now covers the window as well: a partially missing window warns and is averaged over the remaining images, a window without any data raises. The raised message gained the settings to change, since the empty reference was the confusing part of the report.

The window is deliberately not slid to the next available images. The reference window has to precede the experiment, so moving it would pull an image that may already show smoke into the reference. Averaging over fewer clean images is safe; silently picking a later one is not.

Execute Ledsa Expecting Failure and Execute Ledsa Expecting Warning are new acceptance keywords. Execute Ledsa hands its output to check_error_msg, which aborts the whole suite as soon as anything reaches stderr, so neither a reported error nor a warning could be asserted through it.

Verification

• Unit tests: 43/43 pass, five of them new in ledsa/tests/UnitTests/test_reference_intensities.py: a complete window averaged without a warning, the reported single-image case, an unreadable first image of a larger window, a window reaching past the analysed images, and the settings named in the raised message. make_solver gained num_ref_imgs and defaults ref_img_indices to None.
• Acceptance suite: 23/23 pass, including a new case in 07_test_corrupted_images.robot that truncates test_img_1.jpg, runs -s3_fast and --analysis with the default configuration, and asserts the run stops naming the missing reference image.
• Analysis Reads The Column Names From The First Existing Result File from Read the column names from the first existing step 3 result file #143 now asserts the warning instead of running into it. Its num_ref_images = 2 window still names image 1, and the first full run of the suite aborted on exactly that warning before the keyword existed.
• Checked that nothing else trips the new report: the demo covers its window of 10 with 275 images, config_stacked.ini of the acceptance tests sets num_ref_images = 1, no except ValueError swallows the raise, and the averaged path keeps its head rows under their original IDs.

Not covered: average_all_fitpar takes the reference head positionally (iloc[:num_ref_imgs]) while the solver selects by ID, and it renumbers the averaged tail from num_ref_imgs + 1. With a skipped image those two numbering schemes look like they can collide on an img_id. Not reproduced here, so it needs a test of its own.

🤖 Generated with Claude Code